Client/server computing has become more and more widespread over the past few years in the information technology world. Communication in a client/server, distributed environment is important and allows one entity (the client) to delegate an operation (that defines work to be done) to another entity (the server) that might, for example, be on a different machine and be better suited to perform the operation. A typical request for an operation comprises one or more portions for example, an identifier to identify the operation, arguments that are used when executing the operation etc. Once the operation has executed, a reply can be sent to the system on which the client entity is running. Note that the term “client” is used to refer to an entity that sends a request and the term “server” is used to refer to the entity that receives a request. Generally all servers are capable of behaving as clients.
The client entity and server entity can be developed in different formats (e.g. different national languages, different character sets (e.g. Double Byte Character Set (DBCS)—wherein two bytes are used to represent each character, Single Byte Character Set (SBCS)—wherein one byte is used to represent each character). Therefore, a request for an operation developed in one format will not be compatible with the operation developed in another format.
This problem will now be described with reference to a distributed communication mechanism in an Object Oriented (OO) environment. In the OO environment, an object includes data and operations, known as methods that operate on the data. A method has a name (i.e. an identifier), a set of parameters (input, output), a return value and a set of exceptions (usually only relevant for a failure) that can be returned as a result of executing the method. Together these form the signature of a method. The data and methods are tightly bound together within the object, and this integration is known as encapsulation.
A client entity (i.e. a client object) can request a server entity (i.e. a server object) to carry out work on its behalf. For example, when a client object wishes to make a request to invoke an operation on a server object, it first locates a server that supports the server object. Having found a suitable server it then sends it the request. The request may comprise a method to be called with a list of input and output parameters, wherein the method defines the task to be done. The method is invoked by program code on the server, which executes the method on the server object, and results (e.g. a returned value, a data structure, an exception etc.) can be returned to the system on which the client object is running.
The methods available on the server object are determined at object development time. In general, an object's interface provides a set of definitions for method signatures. The client object (and any other client object) must use the set of definitions (and therefore a method name of a method signature) to access the server object. The set of definitions (and therefore the method names that they define) is format specific. Therefore, a client object that sends a request in a different format to the server object is incompatible with the server object.
Prior art mechanisms that address this problem are available. A first mechanism in the OO environment is a “wrapper”. In an environment wherein a client object is constructed in a first format and a server object is constructed in a second format, a wrapper adapts the interface of the server object so that it is compatible with the first format of the client object. Thus, when the client object sends a request in the first format, the wrapper translates it into the second format for consumption by the server object. Likewise, when the server object sends a response in the second format, the wrapper translates it into the first format for consumption by the client object. Although this mechanism allows incompatible objects to communicate, there is a performance overhead involved and furthermore, development of wrappers can be time consuming and complex.
A second mechanism in the OO environment uses duplicate objects, each having method names constructed in a particular format. For example, a server object with method names constructed in a first language (e.g. German), is duplicated, wherein each duplicated object has method names constructed in another language (e.g. a duplicated object with method names in English, a duplicated object with method names in Swedish etc.). Therefore, a client object constructed in English, can access a duplicated server object that has method names constructed in English. Disadvantageously, this system is inefficient as there is duplication of code.
A third mechanism is to provide several format specific versions of an operation in a dynamic link library (DLL) (i.e. a DLL comprising the operation constructed in French, English, German etc.), or to have one format specific version of the operation per DLL (e.g. a DLL comprising the operation constructed in French, another DLL comprising the operation constructed in English etc.). In an example, before an entity constructed in English can request an operation on an entity constructed in French, a DLL is set up comprising the operation constructed in French. Next, the entity constructed in English needs to know the location of the DLL, so that it can call that DLL when required. This causes the operation constructed in French to be executed. In this example, although incompatible entities can still communicate, the requesting entity needs to have knowledge of the DLL.
There is a need for an improved mechanism to allow client and server entities to communicate if they are developed according to different formats.